2026-06-10 AI Agent 记忆系统 拷问复盘
本轮概览
- 知识点：AI Agent 记忆系统
- 模块：5. AI Agent 架构
- 分数：78
- 是否过关：否
- 来源卡片：[[../5. AI Agent 架构/AI Agent 记忆系统]]
第 1 题
题目：
如果面试官问你，为什么 Agent 不能只保存“聊天记录”，而必须单独设计一套“记忆系统”？你要怎么回答？要求你讲清楚短期记忆、长期记忆分别解决什么问题，以及如果不做这套分层设计，会出现哪些工程后果。
你的回答：
你答到了核心问题：只保留聊天记录会带来上下文噪声大、时效性差、结构化组织困难、信噪比低的问题，也能区分短期记忆负责当前会话，长期记忆负责个性化沉淀。
缺失点：
- 没直接打出行业里更高频的关键词，比如
Token 账单爆炸、中间迷失、上下文腐化。 - 对“不分层的工程后果”讲得还不够硬，少了跨会话画像丢失、窗口膨胀、老信息污染新决策这些后果。
- 最后一句有点被问题带偏，面试里不要反问题意，要顺着把答案打满。
推荐答案：
Agent 不能只保存聊天记录，因为聊天记录是流水账，记忆系统是经过筛选、压缩、提纯、更新后的结构化事实库。短期记忆服务当前会话，保存任务状态、意图、中间观察结果，保证这一轮对话不断片；长期记忆独立于 Session，沉淀用户偏好、历史决策和稳定画像，服务跨会话个性化。
如果不做分层，只把历史聊天一直往上下文里堆，会出现窗口膨胀、Token 成本快速上升、中间关键信息被淹没、旧信息持续污染当前决策，而且一旦会话关闭，用户画像也没法长期保留。
项目口径：
在苍穹外卖 AI 客服里，我不会把所有历史对话原封不动喂给模型，而是把当前退款、订单查询这些执行态信息留在短期记忆里，把用户口味偏好、常用地址、历史决策这种稳定事实沉到长期记忆里。这样既能保证当前任务不断片，也能让下次新会话直接继承个性化画像。
第 2 题
题目：
如果让你在生产环境里设计“长期记忆写入链路”，你会怎么做？要求你讲清楚这几个点：什么时候写、同步还是异步、写入前怎么过滤、怎么防止把幻觉或噪声写成“假记忆”，以及如果用户后面改口了，旧记忆怎么处理。
你的回答：
你答对了主干：业务执行和回复结束后异步写入长期记忆，做结构化提取和置信度校验，低于 0.7 不写；同时提供 API 供用户审计和修改。随后你又补上了结构化类型要区分处理，比如操作记录追加写入，口味偏好覆盖写入。
缺失点：
- 过滤规则还可以更完整，比如不落工具原始返回、不落一次性噪声、不落未确认事实。
- 冲突处理虽然提到了“追加”和“覆盖”，但还缺一个统一原则：新事实覆盖旧事实时要保留审计痕迹，而不是直接物理删除。
- 可以顺手补一句“异步落库是为了不阻塞首包时延”，这样工程感更强。
推荐答案：
我的做法是在一次任务完成后异步提纯写入长期记忆，而不是同步卡在主链路上，这样不会拖慢首包时延。写入前先做规则预筛和结构化提取，只保留高价值、可复用、相对稳定的事实，比如偏好、禁忌、常用地址、历史决策；低置信度、未确认、一次性噪声、工具原始回包不写。
为了防止假记忆污染，我会做置信度阈值、事实类型白名单、用户可审计修改，以及新旧冲突治理。像操作记录这种时间序列事实适合追加写；像口味偏好、联系方式这种当前状态事实适合覆盖写，但旧值要保留版本或审计记录，防止后续追不回来。
项目口径：
在我的项目里，长期记忆不是模型想写什么就写什么，而是先经过规则和置信度双重过滤，再分类型入库。比如“用户喜欢少辣”这类偏好可以覆盖更新，“用户今天申请过一次退款”这类操作事实则按事件流追加，这样既保住个性化能力，也避免把幻觉当真相长期固化。
第 3 题
题目：
很多人会把“长期记忆”和 “RAG” 混在一起讲。你现在直接回答两者的本质区别：它们分别存什么、服务什么场景、为什么不能混着注入；然后再补一句，在短期记忆这层，如果高频 FAQ 太多，你会怎么做性能优化。
你的回答：
你区分出了两者的大方向：长期记忆存个性化信息，服务用户体验；RAG 存共享知识，解决公共知识时效性和长文档无法直接喂给模型的问题。性能优化上你也明确说了要做缓存，并且提到了本地缓存加 Redis 保证多节点一致性。
缺失点：
- “不能混着注入”的原因讲得还不够彻底，重点应该是数据边界和注入分区，而不只是“噪声变大”。
- FAQ 缓存部分的表达有明显混乱，
CopyOnWriteArrayList和本地语义检索这套说法不够稳，面试里容易被追问穿。 - 最好的表述应该是“静态 FAQ 先走本地语义缓存，命中直接短路；未命中再走 RAG 或模型”，不要把不必要的数据结构细节讲复杂。
推荐答案：
长期记忆和 RAG 的本质区别在于：长期记忆存的是用户个性化事实和历史决策，服务跨会话个性化；RAG 挂的是共享知识库，服务知识补全、时效性更新和长文档检索。两者不能混着注入，是因为它们的数据来源、可信边界和用途都不同。个性化偏好应该按用户隔离注入，公共知识应该按权限和业务域检索注入；如果混在一起，很容易把用户偏好和共享规则搅乱，造成上下文噪声、越权召回和错误决策。
短期记忆层如果 FAQ 很多，我会在前置链路加本地语义缓存，先做相似度匹配，命中后直接返回，未命中再走 RAG 或模型推理；多节点场景下再用 Redis Pub/Sub 或版本号广播保证本地缓存一致性。
项目口径：
在苍穹外卖 AI 客服里，RAG 负责挂退款规则、配送政策、平台说明这些共享知识，长期记忆负责挂用户口味、常用地址、历史偏好这些个性化事实。对高频 FAQ，我会把静态问答做前置语义缓存，命中就直接短路返回，把大模型留给真正复杂的长尾问题。
下次复习动作
- 把第 1 题的痛点口播固定成四个词：
Token 爆炸、中间迷失、跨会话失忆、上下文腐化。 - 把第 2 题的长期记忆链路固定成一句顺序：
异步提纯 -> 规则预筛 -> 置信度阈值 -> 分类型入库 -> 用户审计修正 -> 冲突治理。 - 把第 3 题的 FAQ 优化话术收敛一下，别再讲不稳的数据结构，优先讲“本地语义缓存 + 未命中再走 RAG/模型 + Redis 保一致性”。